fix: transient ordering bug in ListBuckets integration test - #3

What failed. Case 9 of UnsignedStreamingPayloadTrailer_invalid_chunk_size sends a 36 KB aws-chunked body that the gateway rejects about 8 KB in. The gateway answers and closes the socket while the client is still writing, the Linux kernel replies to the in-flight write with a reset, and Go's HTTP client reports the write error instead of the S3 error the gateway produced. The earlier SignedStreamingPayload_invalid_chunk_size failure on #2 is the same race.

The fix. A port of the upstream body-drain middleware from versity PRs versity#2345 and versity#2378. After the handler chain decides a response, the middleware reads and discards whatever is left of the request body, capped at 256 KB with one-second idle and five-second total deadlines, so the client can finish writing and read the real error. It also marks the connection Connection: close whenever the body was not fully consumed, which stops leftover upload bytes being parsed as the next request on a keep-alive connection. That second point is a genuine correctness fix, so this is worth carrying regardless of the flake.

What changed. Seven files, all under s3api. The middleware and its tests are new. Three middlewares now take the body through the tracking wrapper instead of the raw fasthttp stream, one context key is added, and the middleware is registered in server.go right after panic recovery. Upstream had moved context keys into an internal/httpctx package our tree lacks, so I put the new key in our existing s3api/utils/context-keys.go and took the drain files from the versity#2378 merge commit with the module path rewritten. The upstream authors are niksis02 (ca8d434, d383e1f) and Ben McClelland (c366966) if you want to credit them in the commit.